Process control systems, like those used in chemical, petroleum or other processes, typically include one or more process controllers and input/output (I/O) devices communicatively coupled to at least one host or operator workstation and to one or more field devices via analog, digital or combined analog/digital buses. The field devices, which may be, for example, valves, valve positioners, switches and transmitters (e.g., temperature, pressure and flow rate sensors), perform functions within the process such as opening or closing valves and measuring process parameters. The process controllers receive signals indicative of process measurements made by the field devices and/or other information pertaining to the field devices, use this information to implement a control routine, and then generate control signals that are sent over the buses or other communication lines to the field devices to control the operation of the process. In this manner, the process controllers may execute and coordinate control strategies using the field devices via the busses and/or other communication links communicatively coupling the field devices.
Information from the field devices and the controllers may be made available to one or more applications (i.e., software routines, programs, etc.) executed by the operator workstation (e.g., a processor-based system) to enable an operator to perform desired functions with respect to the process, such as viewing the current state of the process, evaluating the process, modifying the operation of the process, etc. Many process control systems also include one or more application stations. Typically, these application stations are implemented using a personal computer, workstation, or the like that is communicatively coupled to the controllers, operator workstations, and other systems within the process control system via a local area network (LAN). Each application station may execute one or more software applications that perform campaign management functions, maintenance management functions, virtual control functions, diagnostic functions, real-time monitoring functions, safety-related functions, configuration functions, etc. within the process control system.
The software elements (e.g., programs) used to implement the various applications of many process control systems typically rely heavily on the use of object-oriented programming technologies and architectures. Such object-oriented programming technologies and architectures are based on a hierarchical arrangement of software objects in which higher level (e.g., more complex) software objects are built from and, thus, inherit, the properties of one or more lower level objects. The heavy use of inheritance within these object-oriented programming constructs enables a high degree of code (i.e., software instructions, programs, etc.) sharing, which tends to significantly reduce the overall amount of code or software required to implement the control system.
Although known object-oriented programming constructs can advantageously reduce the amount of software or code needed to implement a relatively complex process control system, the high degree of inheritance or code sharing associated with these constructs results in a high degree of dependence (e.g., data dependencies) between the various software routines or components making up the control system. As a result, independent development and/or versioning of these various software routines may be difficult or impossible. For example, in some process control systems employing the above-mentioned object-oriented constructs, the process control system applications (e.g., process monitoring applications), database services, and runtime services are tightly bound (i.e., are highly dependent on one another). In particular, client applications may be built on a common set of data components representing data in the database. Thus, any change in the common data components requires the client applications to be rebuilt. As a result, the data dependencies inherent in these known objected-oriented process control software architectures make independent versioning or development of the database components and runtime software components very difficult or impossible, particularly in cases where different software components of the process control system are developed in different locations (i.e., development sites or centers). To address the data dependencies inherent in these known object-oriented architectures, process control software developers have been forced to closely coordinate the development of database, runtime, and system software components so that these components are built and released in a unified manner.